為什麼以太坊無法實現交易級別的 Parallel 處理？

在追求更高 TPS 與可擴展性的區塊鏈設計中，交易並行處理（Parallel Transaction Execution) 成為一個熱門話題。像是 Aptos、Sui 等新世代公鏈紛紛主打交易層的非同步執行或平行化執行能力。

那麼問題來了：

作為智能合約平台的領頭羊，以太坊為什麼無法實現交易級的並行處理？

隨著我對以太坊技術實現的原理深挖，逐漸發現了從根本上的問題。

以太坊的交易處理流程簡述

首先我們要先盤一下以太坊的交易處理流程．

以太坊的交易處理，是建立在一個同步、單執行緒、順序化的執行模型上。流程如下：

• 1. 出塊節點選出
• 2. 根據共識機制，選出一個節點負責出塊。
• 3. 從交易池抓取 PENDING 的交易
• 4. 按照 Gas Price 等排序規則，選取一批交易（最多填滿區塊 gas limit 為上限）。
• 5. 依序執行交易（同步）
• 6. 對每筆交易進行驗證與執行。
• 7. 每筆交易執行後，會改變當前產塊節點的世界狀態（state）—— 儲存在 Merkle Patricia Trie（MPT）中。
• 8. 如果交易失敗（如餘額不足或 nonce 不對、revert），則跳過，不納入區塊。
• 9. 全部交易試算完成後，計算交易根（txRoot）、收據根（receiptsRoot）、狀態根（stateRoot），將它們封入區塊中，廣播區塊資料到整個網路。
• 10. 其他收到區塊的驗證節點重演執行 5 ~ 9 步驟．

其他節點收到區塊後，會根據交易順序，從頭至尾重新執行這些交易，並驗證最終狀態根是否一致。收到的 stateRoot 是否等於同步交易之後自己節點上的 stateRoot

為什麼無法並行處理交易？

1. 單節點執行模型（Single Block Producer）

   • 區塊的產生由單一節點（Proposer）負責，這個節點會獨立執行所有交易來產出區塊。
   • 即使其他節點有多核處理能力，也只是負責重演驗證，並不參與交易執行。

2. EVM 是一個順序的狀態機（Global Sequential State Machine）

   • 每筆交易都會改變世界狀態（State）。
   • 狀態變更是線性、累積且不可逆的。
   • 如果同時執行多筆交易，且它們互相影響（如存取同一帳戶或合約），就可能出現執行結果分歧。

3. 缺乏靜態可分析的 Access List

   • Ethereum 的交易格式中，無法預知交易會存取哪些 state（storage slot）。
   • 所以無法在執行前靜態判定哪些交易可以並行執行，必須逐筆順序處理以防止衝突。

4. 執行結果需全網一致

   • 所有節點在驗證區塊時，必須根據相同順序執行所有交易，得出一致的 state root。

   • 假設交易順序不同，即使是同一批交易，也可能導致：

     • 餘額不足錯誤（balance error）
     • nonce 不一致
     • 最終狀態錯誤

   舉例：

   執行三筆交易，針對一個空餘額帳戶：
   
   節點 A 執行順序	結果
   +100 ETH → +100 ETH → -200 ETH	成功
   
   節點 B 執行順序	結果
   -200 ETH → +100 ETH → +100 ETH	第一筆交易就因餘額不足失敗
   

5. GAS 模型 + REVERT 機制不利平行處理

• Ethereum 的 Gas 與交易失敗回滾是執行中才會確認的，因此整體只能使用同步、確定性的執行邏輯。